\subsection{Approach Overview}
\label{sec:ApproachOverview}

The challenges identified in the previous Section concern three aspects in \textsc{Mds}: the \emph{conceptual approach} (separation of concerns), the \emph{design of security policies} (abstraction, expressiveness and mapping), and \emph{their management at runtime} (monitoring and reactivity, and policy runtime updating). 

The ``separation of concerns'' philosophy at the core of \textsc{Mds} would suggest to keep both structures separated as long as possible. This contrasts with the usual approach, especially \textsc{Uml}-centric approaches, for which business models are enriched with security-related extensions, i.e. profiles or stereotypes, at the metamodel level (cf. \cite{Basin2006a,Jan2002,moebius_securemdd:_2009}, among others). This prevents security rules from considering properties at the model level, occuring when the application is running. Often though, \textsc{Ocl} expressions are used to partially overcome this issue, but this technique is not powerful enough to express, for example, scenarios where instances of interest intervene as field and parameter values at the same time. 

We propose \SAR, a non-intrusive \textsc{Dsl} for fine-grained specification and for enforcement of access control policies, with runtime policy updates. Although we use Java in our example and validation, \SAR suits well with any object-oriented language for implementing business application, with a few adaptations. In fact, \SAR relies on a simplified meta-representation of the application's dynamic state and the policy runtime status, easily adaptable to other languages. 


\begin{figure}[t]
	\center
	\resizebox{0.7\textwidth}{!}{\includegraphics{Approach.pdf}}	
	\caption{\textbf{Approach Overview:} \SAR is composed of different sublanguages: Static Mapping (\textsc{Sm}) between both specifications; Security Rules (\textsc{Sr}) for expressing policy rules; Rules Status (\textsc{Rs}) representing the dynamic status of rules; Dynamic State (\textsc{Ds}) maintaining a representation of the application's state; Dynamic Binding (\textsc{Db}) for defining rules contexts and action scenarii. The Policy Decision Logic (\textsc{Pdl}), connected to several components, sends access control decisions back to the application runtime.}
	\label{fig:approach}
\end{figure}


Figure \ref{fig:approach} describes how \SAR's components fit into the classical \textsc{Pep/Pdp} approach. Vertically are represented security and business concerns; horizontally are represented specification and runtime artifacts. \SAR fits in the middle, bridging all these dimensions together. At the specification level, a Static Mapping (\textsc{Sm}) declares relationships between the policy and the application specification artifacts (cf. Sec. \ref{sec:StaticRules}). \SAR naturally includes a language for specifying policies, in a textual form close to security experts practice (permissions, obligations and prohibitions). \SAR maintains an abstract representation of the runtime artifacts: the Rules Status (\textsc{Rs}) (i.e. is a rule active, violated, etc.?) and the application's Dynamic State (\textsc{Ds}), which tracks the minimal changes occuring within the applications to be able to evaluate the rules. Security experts can then use this representation to define fine-grained security rules using a dedicated Dynamic Binding (\textsc{Db}) pattern language. 


The \textsc{Pep} monitors the application, using Aspect Oriented Programming (in our case, AspectJ), and filters out the information not relevant for the policy on the basis of the Static Mapping declarations. Currently, we track down three events: instance creation, i.e. a new relevant subject may appear; instance field updates, i.e. relevant values for the policy may have changed; and method calls, i.e. an action can have been initiated. When a relevant method call is detected, the \textsc{Pdp}, namely the Policy Decision Logic (\textsc{Pdl}) implemented in Prolog, computes a decision by matching the Dynamic Binding patterns to the dynamic state (for both the application and the rules). If the access is granted, the execution proceeds; otherwise, a runtime security exception is raised, delivering an appropriate message.